-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update calloop and wayland-rs to the latest versions #404
Conversation
0038f1d
to
65770c7
Compare
Should be good now. |
ce68a13
to
62f8691
Compare
@@ -652,6 +653,8 @@ impl DataDeviceHandler for DataDeviceWindow { | |||
(o, d, Some(t)) => (o, d, t), | |||
_ => return, | |||
}; | |||
// SAFETY: it's safe as long as we don't close the underlying file. | |||
let f: &mut fs::File = unsafe { f.get_mut() }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is annoying, though I'm not sure of a better way to do it here or in calloop while preserving IO safety. (And also not over complicating things; like manual syscalls with rustix instead of using File
methods).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I've discussed this in #calloop channel, basically the issue is that NoIoDrop
thing can't be re-wrapped by us...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, with the alternative of doing a dup
, but there's no way I'll do a dup
for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dup
works, but yeah, not great. Technically also perfectly safe to define a struct implementing Read
using rustix::io::read
on the fd... but that would be rather verbose if nothing else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I'm thinking in the case of SCTK, handling pipes from data device would be a place where using the futures/IO adapters from calloop could make quite a bit of sense 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about Futures, but yeah, if we write a specialized object which simply read/writes maybe it'll be nicer in the end, I just ported the API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could make further (breaking API) changes later to use IO safety in public APIs, probably using Rustix, and not need some of the unsafe
blocks here. But everything should be good here as far as just updating the dependencies.
Should we add a note to the CHANGELOG as part of this PR? I can increment the version and do a release after merging. |
Hm, sure, I can add. |
Suggested-by: Ian Douglas Scott <[email protected]> Fixes Smithay#402.
62f8691
to
25ffa9c
Compare
I've added that we basically updated them, since it's a reexport and is a breaking change. |
Suggested-by: Ian Douglas Scott [email protected]
Fixes #402.
Based on #403, cc @ids1024 @DJMcNab
The calloop wayland source doesn't work and not released yet. Smithay/calloop-wayland-source#1